home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 1 / ETO Development Tools 1.iso / Essentials / MacApp Documentation / MacApp AppleLink Messages / MacApp.Tech$ 12⁄8⁄89 / 0181-Re Failure Handling-Dec89 < prev    next >
Encoding:
Text File  |  1989-12-08  |  1.3 KB  |  31 lines  |  [TEXT/GEOL]
  1. Item    1139562                         8-Dec-89        11:30
  2.  
  3. From:   PASCOE1                         Pascoe, Geoff
  4.  
  5. To:     MACAPP.TECH$                    MacApp Technical
  6.  
  7. Sub:    Re: Failure Handling
  8.  
  9. Jo-Anne,
  10.  
  11. The technique you outline is perfectly fine and will do the job nicely.  For an
  12. alternative techniques see TView.Adorn.  Here, the failure handler employs a
  13. GOTO to go to the last bit of code in the routine that frees the objects (or
  14. handles)-  since they're temps, the routine will normally have to free them
  15. before it exits anyway.  Of course, here you must rely on FreeIfObject to
  16. detect the an already freed object so it won't free it again.
  17.  
  18. Personally, I prefer the nested failure handlers.  It's slightly more verbose
  19. but is more structured and, for me, easier to understand.  Also, I feel
  20. slightly uncomfortable relying on FreeIfObject for detecting anything but the
  21. case where the reference is NIL - I like to be a little bit more in control.
  22. Also for this reason, unlike Curtis, I choose to do the initial NIL assignments
  23. before I start.
  24.  
  25. Geoff
  26.  
  27. P.S.  For clarity, I tend to indent the statements between CatchFailures and
  28. Success, as if CachFailures == BEGIN and Success == END.  For me, it helps make
  29. the situation clearer, especially when the failure handlers are nested.
  30.  
  31.